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We present an external memory algorithm for fast display of very large and complex 
geometric environments. We represent the model using a scene graph and employ different 
culling techniques for rendering acceleration. Our algorithm uses a parallel approach to 
render the scene as well as fetch objects from the disk in a synchronous manner. We 
present a novel prioritized prefetching technique that takes into account LOD-switching and 
visibility-based events between successive frames. We have appli ... 
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Understanding distributed applications is a tedious and difficult task. Visualizations based on 
process-time diagrams are often used to obtain a better understanding of the execution of 
the application. The visualization tool we use is Poet, an event tracer developed at the 
University of Waterloo. However, these diagrams are often very complex and do not provide 
the user with the desired overview of the application. In our experience, such tools display 
repeated occurrences of non-trivial commun ... 
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When implementing persistent objects on a relational database, a major performance issue 
is prefetching data to minimize the number of round-trips to the database. This is especially 
hard with navigational applications, since future accesses are unpredictable. We propose the 
use of the context in which an object is loaded as a predictor of future accesses, where a 
context can be a stored collection of relationships, a query result, or a complex object. 
When an object O's state is loaded, similar ... 
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The purpose of a distributed file system (DFS) is to allow users of physically distributed 
computers to share data and storage resources by using a common file system. A typical 
configuration for a DFS is a collection of workstations and mainframes connected by a local 
area network (LAN). A DFS is implemented as part of the operating system of each of the 
connected computers. This paper establishes a viewpoint that emphasizes the dispersed 
structure and decentralization of both data and con ... 
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Managing scientific data warehouses requires constant adaptations to cope with changes in 
processing algorithms, computing environments, database schemas, and usage patterns. 
We have faced this challenge in the RHESSI Experimental Data Center (HEDC), a datacenter 
for the RHESSI NASA spacecraft. In this paper we describe our experience in developing 
HEDC and discuss in detail the design choices made. To successfully accommodate typical 
adaptations encountered in scientific data management systems ... 
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Contextual information such as spatial location can significantly enhance the utility of mobile 
applications. We introduce the concept of active preferences that represent a combination of 
user preference information and choices combined with spatial or temporal information. 
Active preferences set the policy on how a mobile application should customise its behaviour 
not just for a particular, user but as that user moves to different locations and interacts with 
other mobile users or with fixed lo ... 
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A high-performance implementation of a Java Virtual Machine (JVM) consists of efficient 
implementation of Just-In-Time (JIT) compilation, exception handling, synchronization 
mechanism, and garbage collection (GC). These components are tightly coupled to achieve 
high performance. In this paper, we present some static anddynamic techniques 
implemented in the JIT compilation and exception handling of the Microprocessor Research 
Lab Virtual Machine (MRL VM), ... 
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Two independent recent efforts have defined extensions to the Java platform that intend to 
satisfy real-time requirements. This paper summarizes the major features of these efforts, 
compares them to each other and to Ada 95's Real-Time Annex, and argues that their 
convergence with Ada95 may serve to complement rather than compete with Ada in the 
real-time domain. 
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In this paper, we describe our experience in building an integrated multimedia storage 
system, Prism. Our current Linux-based implementation of Prism provides three levels of 
service: deadline guarantees for periodic applications, best-effort better response times for 
interactive applications and starvation-free throughput guarantees for aperiodic applications. 
Prism separates resource allocation from resource scheduling. Resource allocation is 
controlled across the service ... 
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This article surveys techniques used in structured and object-oriented software specification 
methods. The techniques are classified as techniques for the specification of external 
interaction and internal decomposition. The external specification techniques are further 
subdivided into techniques for the specification of functions, behavior, and communication. 
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After surveying the techniques, we summarize the way they are used in structured and 
object-oriented methods and indicate ways in w ... 
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We report the performance of NOW-Sort, a collection of sorting implementations on a 
Network of Workstations (NOW). We find that parallel sorting on a NOW is competitive to 
sorting on the large-scale SMPs that have traditionally held the performance records. On a 
64-node cluster, we sort 6.0 GB in just under one minute, while a 32-node cluster finishes 
the Datamation benchmark in 2.41 seconds. Our implementations can be applied to a 
variety of disk, memory, and processor configura ... 
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Laurence Nigay, Joelle Coutaz 

May 1993 Proceedings of the SIGCHI conference on Human factors in computing 
systems 

Full text available- m P d«608.88 KB» Additional ,nformation: ML citation, abstract., references, citings, index 
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Multimodal interaction enables the user to employ different modalities such as voice, gesture 
and typing for communicating with a computer. This paper presents an analysis of the 
integration of multiple communication modalities within an interactive system. To do so, a 
software engineering perspective is adopted. First, the notion of "multimodal system" is 
clarified. We aim at proving that two main features of a multimodal system are the 
concurrency of processing and the fusion ... 

Keywords: concurrency, data fusion, design space, modality, multimodal interaction, 
software architecture, taxonomy 
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Reactive behavior is rapidly becoming a key feature of modern software systems in such 
diverse areas as ubiquitous computing, autonomic systems, and event-based supply chain 
management. In this paper we analyze the convergence of techniques from aspect oriented 
programming, active databases and asynchronous notification systems to form reactive 
middleware. We identify the common core of abstractions and explain both commonalities 
and differences to start a dialogue across community boundaries. W ... 
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Full text available: * ^ sdft479.97 KB) Additional Information: full citation , abstract , reference;; , index terms 

Ubiquitous computing requires flexibilty. Melting distributed electronic devices into 
everyday's life implies the need to adapt to evolving standards and dynamic environments. 
Furthermore, to gain user acceptance, such devices should be able to adapt to different 
usage patterns and user profiles. Scalability is also an important issue, allowing functional 
enhancements to already deployed systems. In this work we address these issues applying 
the concept of reconfigurability on different abstract ... 

Keywords: communication, dynamic power management, networks-on-chip, reconfigurabie 
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Well adapted to the loosely coupled nature of distributed interaction in large-scale 
applications, the publish/subscribe communication paradigm has recently received 
increasing attention. With systems based on the publish/subscribe interaction scheme, 
subscribers register their interest in an event, or a pattern of events, and are subsequently 
asynchronously notified of events generated by publishers. Many variants of the paradigm 
have recently been proposed, each variant being specifically adap ... 
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Abstract. When implementing persistent objects on a rela- 
tional database, a major performance issue is prefetching data 
to minimize the number of round-trips to the database. This 
is especially hard with navigational applications, since future 
accesses are unpredictable. We propose the use of the con- 
text in which an object is loaded as a predictor of future ac- 
cesses, where a context can be a stored collection of relation- 
ships, a query result, or a complex object. When an object O's 
state is loaded, similar state for other objects in O's context is 
prefetched. We present a design for maintaining context and 
for using it to guide prefetch. We give performance measure- 
ments of its implementation in Microsoft Repository, showing 
up to a 70% reduction in running time. We describe several 
variations of the optimization: selectively applying the tech- 
nique based on application and database characteristics, us- 
ing application-supplied performance hints, using concurrent 
database queries to support asynchronous prefetch, prefetch- 
ing across relationship paths, and delayed prefetch to save 
database round-trips. 



Key words: Prefetch - Caching - 
— Object-oriented database 
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1 Introduction 

One way to implement persistent objects is to map them to 
a relational database system (RDBMS). This approach has 
two main benefits: it provides persistent object views of exist- 
ing relational databases; and it allows an RDBMS customer 
to build new object-oriented databases without introducing a 
new database engine, thereby avoiding changes to database 
administration procedures and interoperability problems with 
existing applications. The approach is even more attractive 
with object-relational DBMSs, which typically support more 
of the desired object functionality in the database engine it- 
self. The main disadvantage of mapping objects to relations 



is performance, which for many common usage scenarios is 
well below that of object-oriented database systems (OODBs) 
that use storage servers designed explicitly for object-oriented 
access. 

An important feature of persistent object implementations 
(on any kind of storage system) is the ability to load persistent 
objects as active main memory objects, using the object model 
of the application environment (e.g., C++, Java, Smalltalk, 
OMG CORBA, or COM). This minimizes the impedance mis- 
match between the language and DBMS [11], but creates per- 
formance challenges for the database implementation, espe- 
cially when mapped to an RDBMS rather than a custom stor- 
age system. 

One major performance problem is that application object 
models are inherently navigational. That is, objects have ref- 
erences or relationships to other objects, which applications 
follow one at a time. Caching of recently-accessed objects is 
helpful to avoid accessing the RDBMS too often. But even 
with caching, if each access to a non-cached object entails a 
round-trip to the RDBMS. performance will be unbearably 
slow. 

To get a feeling for the performance penalty of round- 
trips to an RDBMS, consider the following simple experi- 
ment: Define a relational database consisting of one table, 
whose 100 000 rows are 100 bytes each. Each row has a 16- 
byte ObjectID column which has a clustered index, three 24- 
byte string- valued columns, and three 4-byte integer- valued 
columns. Suppose the application knows which ObjectID val- 
ues it wants, and it retrieves the rows for 1 00 randomly selected 
keys in batches of 1, 20, or 100 rows. Using a warm server 
cache to factor out the cost of disk accesses, we ran the ex- 
periment on an RDBMS product and retrieved 580 rows per 
second, 2700 rows per second, and 3200 rows per second for 
batch sizes 1, 20, and 100 respectively. 1 This corresponds to 
a retrieval time of 170 ms, 37 ms, and 31 ms for 100 rows. In 



This is an extended version of the paper "Context-Based Prefetch 
for Implementing Objects on Relations," which appeared in the 25th 
VLDB Conference Proceedings. 



1 All experiments in this paper use commodity hardware. The hard- 
ware and software configurations are left unspecified, to avoid the 
usual legal and competitive problems with publishing performance 
numbers for commercial products. Ail performance measurements 
are averages over multiple trials, with more trials for higher variance 
measurements. 
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this case, it is up to 5.5 times faster to get rows (i.e., object 
states) iii a batch of 100 rows than a row at a-time. 

To minimize the performance penalty of database round- 
trips, applications often issue a query to identify the objects 
of interest and then scan the resulting cursor, one object at a 
time. This tells the DBMS which objects to retrieve in batch, 
but often leaves open which pieces of the objects' state are de- 
sired, and hence which tables to access. Moreover, for many 
simple popular navigational patterns, such as following a re- 
lationship, it's a nuisance to issue a query. The application 
programmer would be happier to navigate from one object to 
the next, accessing the objects as she needs them, letting the 
DBMS automatically determine what data to prefetch. Pro- 
gramming interfaces for most OODBs, such as the ODMG 
model [7], satisfy this desire by offering both navigational 
and query access. But how can the DBMS figure out what to 
prefetch in response to navigational access? This is the central 
question addressed by this paper. 

Some OODBs use page servers [17,20]. When access- 
ing an object, the page-oriented OODB (POODB) retrieves 
the page containing the object, and therefore prefetches other 
data on the same page. Thus, by clustering data that will be 
accessed together on the same page, a POODB ensures effec- 
tive prefetching. That is, the clustering approach amounts to 
a static prefetching algorithm. Clustering and prefetching are 
dual problems. 2 

Suppose that whenever a navigational application gets an 
object O for the first time, it shortly thereafter accesses most 
of the objects on O's page - the best case for a POODB, whose 
performance in this case is hard to beat. By comparison, when 
implementing objects on an RDBMS, there is an additional 
query processing step to find the same records that the POODB 
clustered on O's page. Even if the RDBMS clusters the records 
the same way, it still takes more time to find them and gather 
them up for transmission to the application than the POODB, 
which simply ships the page. 

Even if the POODB 's clustering strategy is optimal for the 
average workload, access patterns vary and the page-oriented 
prefetching will make mistakes. Sometimes it will make use- 
less prefetches, where the fetched data isn't subsequently ac- 
cessed. At other times it will miss prefetch opportunities, be- 
cause a predictable access pattern hits objects that are mostly 
on different pages. These mistakes are inherent in the architec- 
ture: static clustering of records and page-oriented accesses. 

A system where objects are mapped to an RDBMS (we'll 
call it an OMRDB) probably cannot match the POODB for 
access patterns that follow the POODB 's physical data clus- 
tering. However, it may be able to earn back some of that lost 
performance, in the following two ways: First, since the OM- 
RDB uses a row server, not a page server, it can prefetch an 
arbitrary combination of rows. That is, it can use knowledge of 
recent application behavior to identify combinations of rows 
worth prefetching, and then use its powerful query processor 
to find and retrieve those rows in one round-trip, whether or 
not the data is physically clustered. By contrast, a POODB 
generally retrieves pages from the server on demand. For a 
given data layout, both OMRDB and POODB will retrieve the 
same number of pages. But query-based prefetching allows an 
OMRDB to prefetch rows before they Ye referenced, reducing 



1 As discussed in the Conclusion section of [12]. 




Fig. 1. Simple example of context-based prefetch 



latency. Second, if the density of desired rows on each page 
is low, then the OMRDB will make better use of client cache 
than a POODB (since it prefetches only desired rows) and 
will use less network bandwidth to transfer prefetched rows. 
Of course, OODBs that use object servers rather than page 
servers can use this OMRDB tactic, so they too can benefit 
from the techniques described in this paper. 

When prefetching objects, an OMRDB has two related de- 
cisions to make: which objects to prefetch and which portions 
of those objects' state to prefetch. To illustrate our technique, 
we focus first on the latter question with a simple example (see 
Fig. 1). Suppose an application accesses relationship R on ob- 
ject 0, which returns a set of objects, S. Suppose the state of 
each object in S is spread across multiple tables. The applica- 
tion may not access all of that state of each object. To avoid 
prefetching a state that the application does not need, the OM- 
RDB delays the decision of which state to prefetch. Instead, 
it simply retrieves the object IDs of the objects in S (making a 
round-trip to the RDBMS) and waits to see what the applica- 
tion does next. Suppose the application selects an object O' in 
S (which is now in application cache) and accesses attribute 
A in O'. This requires another round-trip. But rather than just 
retrieving A for O', the OMRDB retrieves (prefetches) A for 
all objects in S. This is useful if the application later accesses 
A for many of those other objects in S, a very common access 
pattern in workloads we have observed. 

Notice that the prefetch decision is based on the applica- 
tion's access pattern - it is not statically determined. O' could 
be a member of many collections in the database. The decision 
to prefetch A for all objects in S is based on the fact that O' 
was fetched as part of S, and not some other collection. The 
OMRDB must remember this fact in order to use S as the ba- 
sis for prefetching A. This is the core idea of our prefetching 
technique: The OMRDB uses the context in which each object 
is accessed as a predictor of other objects that will be accessed 
later. 

To implement this approach, the OMRDB creates a struc- 
ture context for each object, which describes the structure in 
which the object was fetched. Examples of "structures' 1 are 
stored collections of relationships, query results, and complex 
objects. When accessing some state of an object O, the OM- 
RDB prefetches the same pieces of the state for other objects 
in the structure context of 0, as in the example of accessing the 
attribute A of O' for all objects in the structure context S of O'. 
We call this approach context-based prefetch. As in the above 
example, the approach is beneficial whenever all objects in a 
context undergo similar manipulation. 

The rest of the paper is organized as follows. Section 2 
presents the basic mechanisms for context-based prefetch. 
Since the technique is not cost effective in all situations, Sect. 3 
proposes performance hints to selectively enable the optimiza- 
tions. A summary of our implementation in Microsoft 3 Repos- 

3 Microsoft is a trademark of Microsoft Corporation. 
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itory version 2.0 (in Microsoft SQL Server 7.0) is discussed 
in Sect. 4. Performance measurements in Sect. 5 show up to a 
3-fold speedup due to these optimizations. Section 6 describes 
extensions for asynchronous prefetch, lazy loading of objects, 
and prefetching across paths. Section 7 summarizes related 
work on the general problem of implementing OMRDBs ef- 
ficiently and compares our technique to other published opti- 
mization approaches. Section 8 is the conclusion. 



2 Using structure context 

2. 1 Object model 

To describe details of the approach, we need to define an object 
model. We choose one that is similar to those in common 
use, such as the ODMG model [7], COM [30], and UML [3, 
29]. The approach is largely insensitive to the details of the 
model used here. It should work well for any model that groups 
objects into structures. 

Each persistent object has a persistent state that consists 
of attributes. Each attribute value can be a scalar, an object, 
or a set. 

- Each scalar- valued attribute conforms to a scalar type, 
which gives the name of the attribute and its data type, 
such as string, integer, or Boolean. 

- Every object has a scalar- valued ObjectID attribute that 
uniquely identifies the object. 

- Each object-valued attribute is one side of a binary rela- 
tionship. That is, each relationship consists of two objects 
that refer to each other. 

- Each set- valued attribute contains an object of type set, 
which in turn contains a set of either scalar values or object 
references- The concept of set is a representative example 
of a generic structure type. Other structure types would be 
handled analogously to sets, such as sequence, array, table, 
or record structure, but we do not consider them here. 

Each object conforms to an object type. Each object type has 
a name and a set of attribute types it can contain. Each binary 
relationship conforms to a relationship type, which gives the 
name of the relationship, the two object types that can be 
related, and for each of the two object types, the attribute 
name by which the reference is accessed. 

A class is a body of code that implements one or more ob- 
ject types. It includes a class factory that produces objects that 
are instances of the class. It also includes code that implements 
the usual read and write operations on all of the attributes and 
structures of the object types that the class implements. 



2.2 Operations 

The set of navigational object-oriented operations that we 
consider are GetObject, Get Attribute, GetNext, and Execute- 
Query. These are meant to be a representative sample of the 
kinds of navigational operations found in programming inter- 
faces for persistent object systems. 

- Get Object( ObjectID) returns a running copy of the persis- 
tent object whose unique identifier is ObjectID. 
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- O.GetAttribute(AttrName) returns the value of the 
attribute AttrName from object 0. (The notation O.M 
means execute method M on object 0.) The result is a 
scalar, object, or set, depending on the attribute type. A set 
has an associated cursor, initially pointing to the set's first 
element. 

- S. GetNext either returns the scalar or object identified by 
set S's cursor and advances the cursor, or, if the cursor 
points beyond the end of S, returns null. 

- ExecuteQuery(Q) returns the set of objects that satisfy 
query Q's qualification (as in OQL [7,10]). 

2.3 Database schema 

An OMRDB maps objects to rows of tables. A class maps to 
a table whose columns represent its single-valued attributes. 
Our optimizations are applicable independent of the rules used 
to map attributes of a class to a particular table. However, 
for completeness, we give a few details of mappings that are 
commonly used. 

The simplest mapping is to map a class to exactly one 
table that contains all of the class's attributes. But more com- 
plex mappings are also popular. For example, suppose class 
B inherits from a class A. If both classes are concrete (i.e., 
have instances), then there are separate tables for B and A. 
A's columns, which B inherits, may be stored in both A's and 
B's tables (Fig.2(ii)), or only in A's table (Fig.2(iii), some- 
times called 'Vertical partitioning" [16]). In the latter case, 
B's state is reconstructed by joining A's and B's tables. If A 
is abstract, then its columns might only be stored in tables of 
concrete classes that inherit from it, in which case it lias no 
corresponding table (i.e., in Fig.2(ii), only store Table Tb, 
sometimes called "horizontal partitioning"). 

We assume each many-to-many relationship type is repre- 
sented in a "junction" table. There could be a separate junction 
table for each relationship type, with columns SourceObject- 
ID and TargetObjectID, or a generic junction table for all re- 
lationship types with columns SourceObjectID, Relationship- 
TypelD, and TargetObjectID. Each one-to-many relationship 
can be represented either in a junction table or as a foreign 
key on the "many side." For example, if the one-to-many is 
parent-child, then the foreign key to the parent is stored in the 
child. 

An attribute consisting of a set of scalars can be stored 
in a table with columns ObjectID, AttributelD (short form of 
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the attribute name), and Value. If the set's maximum cardinal- 
ity N is known, it could instead be stored as columns of the 
class's table, such asAttrNamei, . . ., AttrNameN. Since these ' 
two table structures are isomorphic to one-to-many relation- 
ships and single-valued attributes (respectively), the prefetch 
scenarios for a set of scalar attributes are isomorphic to those 
other two cases as well and therefore are not treated further in 
this paper. 



2.4 The prefetch pattern 

As discussed in Sect, 1 , the main approach is to maintain a 
structure context (or, more simply, a context) for each object, 
which describes the structure in which the object was loaded, 
and to use that context to guide later prefetch decisions. In this 
section, we explain one usage of the approach in detail. We 
reapply this usage to other operations in the next section. 
Consider the following operation sequence: 

a. S = O.GetAttribute(R), which returns a set S of objects, 
which is the value of relationship attribute R. 

b. 0' = S.GetNext, which returns an object 0' in S. 

c. V=0'.GetAttribute(A), which returns the value V of scalar- 
valued attribute A of 0'. 

This is the scenario of Fig. L Attribute A corresponds to a 
column of a table, T, containing (some of) the state of the 
class, C, of 0'. Unless T is very wide (e.g., has lots of long 
columns), it costs little more to retrieve all of T's columns that 
are part of C's state than to retrieve only A. This is because 
most of the cost is in the disk accesses, which retrieve all of 
the columns from disk whether or not they are fetched by the 
OMRDB. Thus, if there is a good chance that some of those 
columns will be accessed, then it is worth prefetching all of 
those columns of T for O'. Moreover, since 0' was retrieved 
via S, if we expect other objects in S to be accessed similarly 
to 0\ then we should prefetch all of those columns of T for 
all objects in S, not just for 0\ This avoids later round-trips 
to the database for each object in S. 

The optimization is illustrated in Fig. 3. Table T is shown 
in Fig.3(i), with relationships, such as R, implemented by 
a junction table J. Steps (a) and (c) above are illustrated in 
Fig. 3(h) and (iii) respectively. Notice that Step (c) uses the 
same selection clauses for J as Step (a), and then joins with T 
to get the columns of T for all objects in O.GetAttribute(R), 
not just for O'. 

The experiment in Sect. 1 suggests this prefetch is prof- 
itable if at least 4-5 items in the collection are later accessed 
(since batch retrieval is 4-5 times the cost of a single-row 
retrieval). However, the addition of object- level processing 
reduces the fractional contribution of DB round- trips to to- 
tal cost. Thus, in our experiments, across a variety of work- 
loads and database profiles, the prefetch is profitable if at least 
3 items are subsequently accessed (for our combination of 
data server, network, etc.). The more items accessed, the more 
round-trips saved by the prefetch, and hence the greater the 
benefit. 

If objects in S have state in two tables, T and T', is it worth 
getting attributes from both of them? Usually not. For example, 
we extended the experiment in Sect. 1 by duplicating the table, 
to model T and T'. Getting 100 rows from both tables in one 
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Select T.* 
From J, T 

Where (J.Target = T.ObjID) 
And (J.Source = '(V) 
And (J.RelType - 'R') 
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Fig. 3. Prefetching scenario 

round- trip added 50% to the execution time over retrieving 
only from T. So the cost of needlessly getting the columns of 
V is high. Also, the benefit is modest, since retrieving those 
rows from both tables was only 1 9% slower in two round-trips 
than retrieving the join in one round-trip. Thus, one should 
only retrieve the columns of V if they are almost certain to be 
needed. 

Since the technique heavily uses cache, the interactions of 
prefetching and cache management need careful attention. For 
example, if the cache is nearly full or if the data to prefetch is 
very large, then the prefetch may not work well. We will see 
other examples of this later. 

To generate the SQL query shown in Fig. 3 (iii), the OM- 
RDB needs the context of O'. The context should include the 
information that was used to create the set S initially, namely, 
the object ID of the relationship's source, O, and the rela- 
tionship name, R. These are the parameters that are needed to 
construct the SQL query, which retrieves the desired attributes 
of all objects in the context. 

We expect it is worth supporting variations of this pattern 
where only attribute A or a predefined subset of attributes is 
retrieved, and not all the attributes of its table. However, as this 
is only a slight variation of our main idea, we do not consider 
it further in this paper. 



2.5 Case analysis 

We generalize Sect. 2.4 to other navigational access patterns 
that suggest future navigational behavior. These suggestions 
lead naturally to prefetch recommendations, which retrieve 
the data needed to service the later accesses before those ac- 
cesses occur. Of course, recent navigational accesses don't 
guarantee that those later accesses will occur, so prefetch rec- 
ommendations must be applied selectively, an issue we will 
discuss in Sect. 3 . For now, we simply describe potentially 
useful prefetches and how to implement them, for each of the 
operation types in Sect. 2.2. 

hi the following descriptions, we omit the initial test to de- 
termine if the requested data is already in cache and therefore 
does not need to be fetched. 

GetObject(ObjectlD) - Prefetch some or all of the object's 
state. Note that to load the object into mam memory, the OM- 
RDB only needs to know the object's class (to know what class 
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Fig. 5. Prefetching attributes of referenced objects 



to instantiate) and that the object exists (to know whether to 
return an error). Prefetching other object states is optional at 
this stage. Set the object's context to null, which means it was 
loaded directly, not as pan of a larger structure. 

O.GetAttribute( AttrName) - where AttrName is the name 
of an attribute in O's class. There are six cases to consider, 
Case (i) - Case (vi) below: 

Case (i) If AttrName is a single-valued object reference, and 
O's context is null, then get the reference to the object from 
the database. If the object reference is stored as a foreign key 
in a table containing other attributes of O, then retrieve those 
other attributes too. 

For example, suppose AttrName is a many-to-one relation- 
ship R from O's class C to class D (see Fig. 4). Suppose C's 
table TcfObjID, Ai, . . A n , FKey) contains scalar attributes 
Ai, . . . , A n of C and foreign key attribute FKey that contains 
the object ID of an object in D related via R. Since getting the 
reference to Od in D involves accessing the FKey column of 
O's row in Tc, prefetch the other attributes Ai 5 . . . , A n of that 
row too. 

If Tc is indexed on the compound key [ObjID, FKey], 
rather than just ObjID, then the query processor can get Od 
without accessing O's row, making it cheaper to retrieve FKey 
by itself. If the index on [ObjID, FKey] is non-clustered, this 
raises the incremental cost of getting attributes Ai , . . A n , 
which should therefore be prefetched too only if there's a high 
probability they will subsequently be accessed. 

Case (ii) If AttrName is a scalar and O's context is null, then 
simply retrieve the attribute. As in Case (i), retrieve other at- 
tributes of O's state that are in the table containing AttrName 's 
column. Here and in Case (i), prefetching those other attributes 
is cost-beneficial if some of them are subsequently referenced. 

Case (iii) If AttrName is a single-valued object reference, and 
the context of O is a set S', then prefetch the reference for 
every object O' in S', not just for O. That is, run one SQL 
statement that returns the ObjectID value of AttrName for all 
objects in S ; . As in Case (i), if the object references are stored 
as foreign keys in a table containing other attributes of O', 
then retrieve those other attributes too. Prefetching the object 
reference for other objects in S' is cost-beneficial if at least 
several other objects in S' are subsequently accessed. This 
case is essentially the same as Case (i) (Fig. 4), except that 



multiple rows of Tc are retrieved (one for each object in S ; ) 
instead of just one (for O). 

Case (iv) If AttrName is a scalar and the context of O is a 
set of objects, then O. Get A ttribute( AttrName) corresponds to 
Step (c) in Sect. 2.4. Do the prefetch described there and in 
Fig.3(iii). 

Case (v) If AttrName is set- valued and the context of 0 is null, 
then retrieve the set's content for O, which is a set S of either 
scalar values or objects. Tn the latter case, assign S to be the 
context of each object in S. 

Suppose S is a set of objects (as opposed to scalars). If Attr- 
Name is a one-to-many relationship, then the references from 
O to objects in S can be stored as O's foreign key in the objects 
in S. So, when accessing AttrName, retrieve other attributes 
of the objects in S that are stored in the same table as the for- 
eign key. Modifying the example of Fig. 4 so that AttrName is 
a one-to-many (rather than many-to-one) relationship R from 
O's class C to class D, we get Fig. 5, where Bi , . . . B m can be 
retrieved along with objects in D referenced by O. As usual, 
prefetching those other attributes is cost-beneficial if some of 
them are referenced later for at least several other objects in 
S. 

If S is a set of objects and AttrName is a many-to-many 
relationship, then the references from 0 to objects in S must be 
stored in a junction table Ta, as shown in Fig. 6. In this case, 
attributes of D are not stored in the same table as the relation- 
ship. Retrieving them requires an extra join, so, as in Case (i), 
they should be prefetched only if there's a high probability of 
subsequent access. 

Case (vi) If AttrName is set- valued (i.e., a set of scalars or 
objects) and the context of O is a set S', then prefetch the 
AttrName set for every object in S'. For example, if AttrName 
is a relationship R to a set of objects, then execute one SQL 
statement that prefetches ObjectlDs of members of the R set 
of every object in S'. That is, the SQL statement returns a table 
of (ObjIDi, ObjID 2 ) pairs, where ObjIDi denotes an object 
in S' and ObjID 2 denotes an object referenced by ObjIDi via 
R. This is analogous to Sect. 2.4, where the scalar attributes of 
all objects in S' are prefetched. In addition, for each object Oi 
in S', for each Oj ; k in Oi's R set, assign Oi's R set to be the 
context of Olr. The prefetch is cost-beneficial if those R sets 
are accessed for at least several other objects in S'. 
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Fig. 6. Prefetching referenced objects in a many-to-many rela- 
tionship 



If R is one-to-many from 0, then Fig. 5 can be viewed as 
an example of this case. R is one-to-many from O's class C to 
class D, and is represented as a foreign key in D's table To- 
However, instead of retrieving AttrName only for 0 (as shown 
in Fig. 5), retrieve AttrName for all objects in O's context. As 
in earlier cases, the attributes of objects in D can be prefetched 
too, modulo the additional cost, depending on whether FKey 
is part of the compound index on To- 

Similarly, if R is many-to-many, then Fig. 6 can be viewed 
as an example of this case. Again, instead of retrieving At- 
trName only for O, retrieve AttrName for all objects in the 
context of O. 

ExecuteQuery(Q) - We apply context-based prefetch to the 
set that results from the execution of a query, just as we do for a 
set of stored object references in Cases (iii) and (iv). We could 
do this by executing the query, saving the resulting ObjectID' s 
in a set, and sending the ObjectlD's to the RDBMS on each 
prefetch. However, this is inefficient for large query results, 
and problematic since the query that does the prefetch could 
exceed the maximum size of a SQL statement or stored pro- 
cedure call. We could re-execute the query on each prefetch, 
but this too would be inefficient unless the query is cheap. 
Therefore, we store the context on the server in a temporary 
table. 

So, assume each session has a temporary table TEMP 
(SetID, ObjectID) in the DBMS. Associate a unique SetID,, 
s, with the query. Map the query into an Insert statement that 
appends rows (s, o) to TEMP for each ObjectID o in the result 
of the query. Execute the Insert and return the ObjectlDs of 
the query result into a set, S, also identified by s. 

Creating this context is cost-beneficial if attributes of the 
objects in S are subsequently accessed, making prefetches of 
those attributes cost-beneficial, and if the query is too expen- 
sive to re-execute to perform the prefetch. 

TEMP can be created any time after start ing the database 
session, but no later than the first call to ExecuteQuery. 

Like any query result, a query context in TEMP can be 
used across transaction boundaries only if the application is 
using read-committed, not repeatable-read, isolation. 

S.GetNext - Return the designated element of S. Prefetch- 
ing was accomplished when S was loaded, i.e., in GetOb- 
ject(ObjectlD) or O.GetAttribute(AttrName). 



2.6 Managing structure context 

Structure context is part of the state of a loaded object. The 
context's lifetime is governed by that of the object. Thus, when 
the object is released, the context is deallocated too. This in- 
cludes context information that is maintained with the object 
by the OMRDB, typically in main memory. Also, when releas- 
ing a set that was the result of an ExecuteQuery, it includes the 
deletion of rows of the temporary table containing the cached 
result of the query. Like any deallocation, the latter can be done 
lazily and asynchronously with respect to other processing. 

As for persistent database tables, the performance charac- 
teristics of temporary tables must be carefully analyzed when 
using them to cache query results. For example, depending 
on how space is managed, it may be important to preallocate 
temporary table space. It may or may not be valuable to have 
an index on SetID, depending on how queries are processed, 
the size of query results, and how many query results are con- 
currently active. 

Suppose an object is loaded multiple times via different 
navigational paths. For example, an application might load 
object 0 via 0 / .GetAttribute( AttrName), where AttrName is 
a set S containing O, and later reload O via GetObject(o), 
where o is O's ObjectID. In some programming interfaces, 
the later operation does not return the same loaded object, but 
rather returns another copy of the same persistent object. If so, 
then one would expect the two objects to share their cached 
persistent object state, since they refer to the same object. 
However, since the two objects were loaded via different paths, 
they should have different contexts. In the example, the first 
object's context is S, while the second's is null. 

2. 7 Avoiding repetitious prefetch 

Blindly applying the prefetches described in the case analysis 
of Sect. 2.5 risks prefetching object state that is already in 
cache. For example, Case (iv) recommends prefetching the 
attributes of all objects in an object O's context, C, whenever 
attributes of 0 are requests. If many of the objects in C already 
have their attributes in cache, then blindly prefetching these 
objects' attributes is wasted effort. The wasted effort includes 
both the retrieval of more data than is needed and the client 
processing needed to load that data into cache. 

The OMRDB can avoid this wasted effort by first identi- 
fying winch objects in C already have their attributes cached 
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and then only issuing a prefetch for the objects in C whose at- 
tributes are not cached. Unfortunately, the benefit of avoiding 
wasted prefetches entails the following two costs: First, enu- 
merating and checking for cached state of O's context is extra 
work. One might expect this enumeration is needed anyway, 
to construct the SQL query that does the prefetch for all ob- 
jects in the context of O. However, this is usually not the case, 
because most contexts have a representation of their content 
that is more compact than a simple enumeration, hi particu- 
lar, if the context of O is a collection that was constructed by 
dereferencing an attribute A of a parent P of O, then the con- 
text can be represented by the pair [P.ObjectID, "A"]. Second, 
using an explicit enumeration of the context leads to more 
verbose SQL statements to perform the prefetch. That is, the 
SQL query needs to include the list of Object IDs of the ob- 
jects that are the subject of the prefetch, rather than using the 
more compact representation, such as [P.ObjectID, "A"], to 
perform a simple join, as shown in Sect. 2.5 Case (vi) and the 
accompanying figures. If the context is large, this potentially 
can bump into restrictions on maximal size of a SQL query 
on some systems. In addition, overhead associated with exe- 
cuting a long query string may mitigate some of the benefit 
of retrieving and processing a smaller amount of data. Still, 
we expect the benefits usually outweigh these costs, making 
it worthwhile to identify cached state before prefetching. 

Many-to-many relationships are a common case where 
data to be prefetched may already be in cache. Consider a 
set of parent objects P 1} . . . , P m , each of which has a rela- 
tionship to n children, C i;1 , .C-^ n (for parent Pi), where each 
child object may be shared by multiple parents. Suppose all 
parents and children are loaded into cache, but the attributes of 
the children are not yet loaded. (Notice that this is an example 
of the scenario of the previous section, where an object (i.e., 
child) is loaded multiple times, each loaded instance having a 
different context.) Using context-based prefetch, an access to 
an attribute of a child Qj triggers a prefetch of that attribute 
for all children in the context of Cy, where that context is 
its parent's collection of children. If children of many dif- 
ferent parents are fetched, then the probability of repeatedly 
prefetching the same children can be high, potentially defeat- 
ing the benefit of the prefetch. We will see an example of this 
in Sect. 5.1. 



3 Performance hints 

Since the prefetch optimizations of Sect. 2.5 are not always 
cost-effective, it is important to be able to enable and dis- 
able them. Enabling an optimization is essentially a perfor- 
mance hint to the underlying OMRDB. This general approach 
of application-supplied hints has been adopted by other object- 
to-relational mapping systems, such as [23], and in other com- 
mercial products [8]. 

The main optimizations that are worth controlling in this 
way are the following: 

1A. Attributes for 1 object - When accessing an object O, 
prefetch all of O's scalar attributes. 

1R. Relationships for 1 object - When accessing an object O, 
prefetch all of O's references to other objects. 



MA. Attributes for Many objects - When accessing a scalar 
attribute A of an object O, prefetch all of the attributes in A's 
table for all objects in O's set context. 
MR. Relationships for Many objects - When accessing a rela- 
tionship attribute A of an object 0, prefetch the objects related 
via A for every object in O's set context. 

It is often appropriate to enable a prefetch optimization for 
an application's entire execution, but sometimes it is not. For 
example, if an application accesses all members of some sets 
but only one member of others, MA will speed up accesses 
to the former and slow down accesses to the latter. Thus, it is 
beneficial to enable and disable the optimizations dynamically 
during its execution. 

Performance hints can be added as tags in an information 
model to specify the default prefetch behavior of a class. For 
example, a class C could be tagged to enable MR but disable 
MA. Such default behavior can be overridden by the applica- 
tion. 

Although prefetch is enabled and disabled dynamically, it 
is still beneficial to maintain context for each loaded object. 
This makes it possible to perform context-based prefetch on an 
object that was loaded when prefetching was disabled. Since 
maintaining context is cheap, there is little benefit to disabling 
it, witii one possible exception: The result of a query is cached 
in a temporary table for use as the context of each object in 
that result. Since adding the result to the temporary table has 
non-negligible cost, it is probably worth disabling in cases 
where it is known to be ineffective. 

Although the manual control that performance hints of- 
fer is worthwhile, it would be even better if the system could 
automatically decide when to enable and disable prefetching. 
One approach is to run the application on sample data to gen- 
erate traces, and then analyze the traces to determine whether 
each type of optimization is cost effective for a given run. An- 
other approach is to statically analyze the application to pre- 
dict certain access patterns. For example, a common pattern is 
to call GetAttribute(R), where R is a relationship that returns 
a set of object references, and then loop through the result, 
accessing attributes of each object. In this case, the program 
would be modified to enable MA before entering the loop. 
Even finer-grained control is possible here, since the exact set 
of attributes that will be referenced could be made known in 
the hint, thereby reducing the cost of the prefetch. 

A cache control mechanism would also be beneficial, to 
reduce the amount of prefetching when the OMRDB 's cache 
is stressed. The cache manager could track the amount of free 
space, for this purpose. 

4 Implementation in Microsoft Repository 

The prefetch optimizations of Sect. 2 are implemented in Mi- 
crosoft Repository 2.0, whose storage engine is a persistent 
object layer implemented on top of Microsoft SQL Server 
7.0. The product's object model, table layout, and API do not 
include all of the alternatives in Sects 2.1-2,3. The differences 
that are relevant to the prefetch optimizations being considered 
here are: 

- All relationships are currently stored in a single junction 
table, such as Table J in Fig. 3(i), not as foreign keys in 
class- oriented tables. 
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- The object model is COM, where classes implement in- 
terfaces, and interfaces have single- valued scalar proper- 
ties and relationship- valued collections. Each interface's 
scalar properties are stored in (i.e., are columns of) one ta- 
ble, each of whose rows contain state for an object whose 
class implements the interface. Each table can store the 
properties of many interfaces, but a class's interfaces need 
not all be stored in one table. 

- There is an additional method, Objectlnstances, that gets 
the set of all objects that are instances of either a given 
class or a class that supports a given interface. Objects that 
are retrieved by this method have the retrieved set as their 
context, which is represented by the identity of the class 
or interface. This is very similar to Case (v) in Sect. 2.5, 
0,GetAttribute(AttrName), where AttrName designates a 
set of object references. 

- Each time a persistent object P is loaded, a new COM 
object is created, which shares its cached state with other 
COM objects that represent P. The context is stored in the 
COM object, since each load operation for P may be via a 
different navigational path and therefore have a different 
context to guide prefetch. 

The object model, table layout, and API are described in detail 
m [1,2]. 



5 Performance measurements 

The prefetch optimizations as implemented in Microsoft 
Repository have been useful for many customer applications 
we have tested, so they are frequently enabled - especially 
MA, which we have found is almost always beneficial. How- 
ever, it is hard to report on these in a way that bears scientific 
scrutiny, since each application yields a varying workload that 
is hard to characterize succinctly. We therefore ran some more 
controlled experiments to show how the optimizations work 
in practice. 

5.1 Experiment 1 - the 007 benchmark 

A good test to show the benefits of MA is the 007 benchmark 
[4,5,6], since it is a highly regular workload that is represen- 
tative of many persistent object applications (a brief summary 
is given in the Appendix). We ran the 007 queries and traver- 
sal using Microsoft Repository on the medium-sized 007 
database (225MB). We ran with a cold server cache, to ensure 
the optimizations are fully penalized for useless prefetches. 
We did not run 007 structural modifications, since their be- 
havior is not affected by our optimizations. 

Queries Q1-Q3 and Q7 are all of the folio whig form: re- 
trieve a set of objects (in our case using ExecuteQuery) and 
access the objects' state. Q8 also accesses state, to form a 
sub-query for each object in an outer query (it retrieves a set 
of object pairs). So they all benefit from optimization MA, 
which prefetches the objects' state in one round-trip based on 
the cached query result. Fig. 7(i) reports the percentage im- 
provement inrurming time over an execution with no prefetch 
optimizations enabled (i.e., [(old - new)/old] x 1 00). The ben- 
efit varies based on the size of the result and the algorithm for 
j oining the TEMP table (containing cached query results) with 
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the attribute table at the server. Query Q4 is of the same form 
as Q1-Q3, but the query plan for the prefetch is sub-optimal, 
making MA ineffective. None of the queries benefit from 1R 
or MR, because they don't access any relationships; neither 
do they benefit from 1A, because only one attribute of each 
object is accessed. Query Q5 simply counts the number of ob- 
jects in the result of a query, so there's no benefit to prefetching 
properties or relationships. 

Traversals T1-T6 navigate relationships starting from a 
root. Each test traverses the three subassemblies of each as- 
sembly, down through six levels. For each leaf assembly, called 
a base assembly, it accesses the three composite parts con- 
nected to the base assembly. It then accesses one or more of 
the atomic parts connected to each composite part (the type of 
atomic part accesses differ for each traversal). 

Like the queries, traversals T2b,c and T3b,c access at- 
tributes and therefore benefit from MA. Tl and T6 do not 
access attributes, so MA has no effect. T2a and T3a access 
only one object in each atomic parts collection, so prefetching 
attributes for all objects is a cost that has no compensating 
benefit. Thus, MA decreases their performance. 

hi principle, traversals T1-T3 should benefit from MR. 
To see why, consider a parent assembly, P, that has three child 
subassemblies, CI , C2, and C3. Without MR, the subassembly 
relationships of CI, C2, and C3 are expanded independently, 
requiring three round- trips. With MR, when CTs subassem- 
bly relationship is referenced, the subassembly relationships 
of CI, C2, and C3 are fetched in one round-trip, since C2 and 
C3 are in CI 's context (namely, the subassembly collection of 
P). Thus, three round-trips to the database server are replaced 
by one. When we ran test T2b, for example, we observed a 
60% reduction in the number of round- trips, in line with ex- 
pectations. 

However, there is a mitigating factor involving the base 
assemblies, winch are the leaves of the hierarchy. Each of 
the 729 base assemblies in the 007 database has a relation- 
ship to three composite parts, and each of the 500 composite 
parts has a relationship to 200 atomic parts. Since there are 
729 x 3 = 2187 relationships from base assemblies to com- 
posite parts, and only 500 composite parts, most composite 
parts are reused in multiple base assemblies. Since we did 
not eliminate repetitious prefetch (as described in Sect. 2.7), 
shared components caused MR to repeatedly prefetch the same 
composite parts many times. The client cost of needlessly re- 
constructing 2187 — 500 — 1687 atomic parts collections of 
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these already-cached shared composite parts washed out any 
benefit of the reduced number of SQL queries. Thus, with 
the current feature set of our implementation, 007 does not 
benefit from MR. 



5.2 Experiment 2 -XML export 

Another application with a highly regular workload is the 
XML export utility that ships with the product. We wrote a 
program that uses the utility to export a set of objects reachable 
from a root, by doing a breadth- first traversal from the given 
root and writing them out as an XML stream. We exported 
a UML model consisting of 3100 objects and 3900 relation- 
ships. The execution time was 267 ms with no optimizations, 
1 1 7 ms with 1 R enabled, 220 ms with MA, and 78 ms with both 
1R and MA. That is, the execution was 56%, 18%, and 71% 
faster with optimizations 1 R, MA, and 1 R+MA, respectively. 

1R helps because in UML each object has many relation- 
ship types, all of which are accessed, either to export them or 
determine that they are empty. MA helps because if a rela- 
tionship is non-empty, then attributes of all related objects are 
exported. These benefits are nearly independent, in that the 
benefit of 1 R+MA (71%) is nearly the sum of the benefits of 
1R and MA (56% + 18°/o=74%). 



5.3 Experiment 3 - Measuring MR 

To measure the benefits of MR in a controlled setting, we cre- 
ated an object hierarchy stored as relationships in a junction 
table like Table J of Fig. 3(i), with a clustered index on its key 
(Source, RelType, Target). The hierarchy has a top-level fan- 
out of 100, and a second-level fan-out of 20. We traversed the 
hierarchy by running SQL. The baseline ran a SQL query to 
get the 100 children of the root followed by a query for each 
child to get its 20 children. To model MR, we replaced the 
100 queries for grandchildren by one query to get all grand- 
children. The latter retrieves the same amount of data as the 
former, but replaces the fixed overhead of 100 queries by that 
of just one query. The resulting execution time was 71% faster 
with MR enabled than disabled. 

MR is sensitive to the size of the context to which it is 
applied, since that affects the number of queries it saves. For 
example, by running the previous experiment on a hierar- chy 
with a top-level fan-out of 20 and a second-level fan-out of 
100, the benefit of MR is only 33%, less than half as much 
as the previous case. The same amount of data is retrieved 
as before, but only 20 queries for grandchildren are replaced 
by one query. Similarly, in XML, MR actually reduces per- 
formance, probably because the contexts are small and the 
prefetch requires an extra expensive join. 



6 Extensions 

6.1 Asynchronous prefetch 

Some contexts are large, causing MA or MR to prefetch a 
large amount of data. Performing this prefetch synchronously 
delays the application's data access that triggered the prefetch. 



This delay is especially worrisome when commumcation be- 
tween the OMRDB and database server is slow. However, even 
with high bandwidth communication, the delay incurred by a 
large prefetch can be significant. 

To some extent, an application can reduce this delay man- 
ually by reordering its logic so that the OMRDB gets data 
before the application actually needs it. However, this is a ma- 
jor programming burden and cannot always be accomplished. 

It would be better to have the system reduce the delay by 
doing the minimal work necessary to return from each data 
access call and prefetch any additional data asynchronously 
with respect to the call. This not only helps reduce application 
delay, but is also useful when the cache is nearing overflow. 
The ability to delay part of the prefetch allows the OMRDB 
to postpone loading the data until enough cache space is freed 
to accommodate the prefetched data. 

Asynchronous prefetch can be done in the OMRDB with- 
out help from the underlying DBMS by partitioning the query 
that performs the prefetch into two queries: one that retrieves 
the data required by the application's data access plus, possi- 
bly, a subset of the data to be prefetched, and a second remain- 
der query that identifies the rest of the data to be prefetched. 
Unfortunately, this isn't always doable. For example, in MA, 
to prefetch attribute values for a large unordered set, we would 
need a column value that partitions the set into non- over- 
lapping subsets, something that we cannot count on in general. 

We can do better by running the prefetch as a single query 
and leveraging asynchrony offered by the underlying SQL 
DBMS. A SQL query returns its result as a set of rows. Using 
low-level mterfaces offered by the data access protocol (e.g., 
via ODBC), the OMRDB can start populating its cache as soon 
as the first packet arrives from the DB server. When the OM- 
RDB has cached all of the data requested by the application, it 
returns to the application, but it continues processing packets 
asynchronously until all the prefetched data has arrived. If the 
application later asks for an item that is still being prefetched, 
it is blocked. 

Ordinarily, as long as a query is active on a database session 
(connecting the OMRDB to the SQL DBMS), the OMRDB 
cannot issue additional queries. Thus, if the application makes 
a data access call that requires an SQL call to the DBMS, it 
may have to wait while the OMRDB finishes prefetching the 
results that were triggered by a previous call. 

To circumvent this problem, many DBMS products, such 
as DB2, Oracle, and Microsoft SQL Server, support multiple 
active statements on a database session. This allows a second 
application request to be executed while a previous request 
is still active. To meet our needs, this feature must allow the 
result of a query to be buffered on the DB server until it is 
explicitly requested by the OMRDB client. We call this feature 
sewer cursors (which is the name used for it in Microsoft 
SQL Server). Using server cursors, the OMRDB can buffer 
the results of several queries on the server. Therefore, it can 
execute a query that performs a prefetch (saving its result in a 
server cursor), load part of the prefetched data into cache, and 
then turn its attention to servicing other application requests 
or prefetches before returning to finish processing the original 
prefetch. 

If server cursors are used and the application abandons the 
object that was the subject of the prefetch, the OMRDB may 
never have to finish loading the prefetched data. For example, 
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suppose we are applying MA to an object 0 in context C, 
where C is a collection. The prefetch retrieves attributes of all 
objects in C. If the application releases its handle on C before 
the prefetch is complete, then the prefetch can stop and the 
cursor is dropped. 

If server cursors are not available, an alternative is to use 
two sessions for each transaction: one session to run syn- 
chronous requests and a second session for asynchronous 
prefetches. However, like multiple statements per session, this 
feature is not universally supported. Some DBMSs do not al- 
low two sessions from one client to be running the same trans- 
action. The main reason for this restriction is that it would 
require adding server support for concurrent nested transac- 
tions, i.e., the server must be able to independently back out 
update statements on each session. 

Streaming the result of a query is useful for ordinary fetch, 
not just prefetch, such as when getting the objects in a large 
collection. However, in some cases, it is unavoidable to fetch 
the entire result before returning to the caller. For example, Mi- 
crosoft Repository stores sequenced collections as rows linked 
by back pointers [ 1]. If an application requests an item of the 
collection other than the first (the first element can be distin- 
guished by its NULL back pointer), then all of the collection 
elements must be loaded into cache for the engine to determine 
the requested item. 

Finally, statistics are needed to determine how much to 
prefetch. The goal is to fetch only a small amount to avoid 
delaying the application much by the prefetch, but to fetch 
enough to keep the application busy while the second, asyn- 
chronous prefetch is running. 

Some contexts are too large to prefetch the attributes or 
relationships for every object hi the context. For this case, one 
could specify a threshold for context size, above which the 
MA or MR prefetch is disabled. 



6. 2 Prefetching across paths 

We can extend context-based prefetch to apply to paths of re- 
lationships. For example, consider a persistent object base that 
contains a database schema definition object, which contains 
table definition objects, each of which contains column defini- 
tion objects, each of which is related to a data type definition 
object. When accessing a column of the first table definition, 
MR will prefetch column definitions of all table definitions. 
We showed in Sect. 5.3 that this can yield significant improve- 
ments. It may also be beneficial to prefetch the scalar attributes 
of those column definitions [i.e.. Sect. 2.5, Case (v)] and their 
relationships to data type definitions (adding another hop to 
the path). To estimate the benefit recall in Sect. 2.4 that getting 
100 rows from two identical tables with 100-byte rows in 2 
round-trips is 19% slower than getting the join in one round- 
trip. One could extend the hints of Sect. 3 to specify when to 
prefetch across such a path. 

An issue with this approach is the representation of the in- 
herently hierarchical result of the prefetch, when a relational 
query is used. As observed in [19], in a parent-child relation- 
ship, when retrieving all the children of a parent, the parent 
information is repeated for every child due to the normaliza- 
tion inherent in relational queries. Possible solutions are to 
return the result in a nested table, a tree structure, or an XML 



stream (that represents the tree structure), all of which require 
some extension to the underlying RDBMS. 

6.3 Lazy loading of sets 

Suppose O.GetAttribute(AttrName) returns a set, S, of objects 
[i.e., Case (v) and Case (vi) in Sect. 2.5]. One could execute 
GetAttribute by storing only its definition [i.e., 
"0,GetAttribute(AttrName)"] and not its instances in main 
memory. If S is used only to insert new objects, then the exist- 
ing state of S never needs to be loaded, a significant optimiza- 
tion. If existing objects in S are retrieved, then its instances 
can be loaded on the first invocation of S.GetNext. 

Suppose it is known that all objects in S are instances of 
the same concrete class C (rather than different specializations 
of C). Now even GetNext can avoid loading an instance of S, 
by creating a hollow instance O' of C. This can be done us- 
ing only cached type information, without accessing database 
instances. The state of O' is populated only when one of its 
attributes is accessed. At this point, MA kicks in; it retrieves 
that attribute (and possibly others in the same table) for all 
objects in S. This prefetch gets the object IDs of all objects 
in S as a side effect, which allows S finally to be populated 
with instances. Thus, the initial round-trip to the RDBMS to 
get the object IDs of objects in S is entirely avoided, leaving 
only one round-trip to get the attributes of all objects in S; the 
number of round-trips in this scenario is halved. 

While this benefit is appealing, unfortunately the line of 
logic to attain it is not quite sound: If S is empty, then 
S.GetNext should return null. If this is known to be impos- 
sible (e.g., because the set has an enforced integrity constraint 
saying it has non-zero cardinality), then the technique works 
fine. Otherwise, if it can return null, then it is not valid for it to 
return a hollow instance of C. Therefore, to benefit from this 
optimization, a change is needed in the programming inter- 
face. There are several options: a hint could be issued before 
the first call to GetNext, to tell the system what attribute(s) 
to prefetch; the GetNext call itself could optionally include a 
list of attributes of interest; or the semantics of GetNext could 
be modified so that the first GetNext on an empty set returns 
an object and an exception is raised only when attempting to 
access one of that object's attributes. The use of a hint strikes 
us as the best of the alternatives. 



7 Related work 

Although much has been published on the implementation of 
persistent objects, very little of it uses an RDBMS as the under- 
lying store. Keller et al. provide a good overview of the issues 
[ 1 6]. Most papers, such as [ 1 8,1 9,2 1 ,27], assume that the set 
of objects to be retrieved is defined by a query, such as [18, 
1 9, 21, 27], where the issues are running the query efficiently 
and assembling the objects in the OMRDB, and caching the 
query result for reuse with later queries [15]. Navigational ac- 
cess is applied to the result of the query, so there's nothing to 
prefetch. Descriptions of some commercial products that map 
objects to relations can be found in [22,26,28,31]. 

Proponents of OODBs have published many white papers 
to show that their products outperform a similar implementa- 
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tion on RDBMSs, but little o f tins has made it into the scientific 
literature. A useful bibliography is [9]. 

Prefetching architectures based on recent reference be- 
havior are described in [12,24]. Palmer and Zdonik use pre- 
analyzed reference traces to guide prefetch [24]. During a 
training phase, they look for recurring access patterns. Popular 
patterns are stored in an associative memory and used to drive 
prefetch during normal operation. Curewitz et al. propose us- 
ing compression algorithms to find recurring access patterns 
[12], Compression algorithms work by determining the prob- 
ability that certain sequences will occur and encode those se- 
quences in a small number of bits. Curewitz et al. treat object 
references as an alphabet over which reference traces (i.e., 
sequences) can occur. Given a reference trace, they use the 
compression algorithm to predict which references are most 
likely to occur next and use those predictions as candidates 
for prefetch. 

Both [12] and [24] look for recurring access patterns. By 
contrast, our approach assumes that applications conform to a 
certain generic navigational pattern, so programs benefit from 
prefetch even the first (and possibly only) time the objects are 
accessed. Since the generic access pattern is not always rele- 
vant, we allow application programmers to influence prefetch 
decisions. To avoid this burden, one possible application of 
[12] and [24] in our setting is to use reference traces to pre- 
dict when context-based prefetching should be enabled. They 
could also be used to determine whether data in multiple ta- 
bles is frequently accessed together and should therefore be 
prefetched in one round-trip. However, it is possible that sim- 
pler analyses of reference traces than these rather sophisticated 
techniques would yield similar benefits. 

Haas et al. investigate ways of prefetching object state 
along with object IDs, the same problem as this paper [14]. 
However, their approach is based on two assumptions that do 
not hold in our environment: first, that query processing can 
be distributed between the database server and the client that 
submits the query (in their case, a middle tier server), and 
second, that the query optimizer can be extended to be knowl- 
edgeable about the caching activity. They include the caching 
activity as a possible step of a query plan. Each caching step 
has a cost, which is the actual cost to cache the data minus the 
benefit of the cached result to reduce the cost of later object 
accesses. They use this cost during conventional cost-based 
query optimization to decide whether to do caching and, if so, 
how much of the query evaluation to do on the server. 

In our case, we face a very similar problem when prefetch- 
ing the result of ExecuteQuery. We assumed we could not mod- 
ify the query optimizer, so we always retrieve the object IDs 
first and retrieve the object state in a separate step. To avoid re- 
calculating the query, we cache the object IDs on the server. If 
the tables containing these objects' state is still in server cache 
when we later access them, then the cost of reassembling the 
object state should not be much different than that incurred 
by Haas et al's approach. If not, then Haas et al.'s approach 
could beat our ExecuteQuery performance, since it gathers 
up the state while the required tables are in cache. However, 
this benefit comes at a substantial engineering cost of imple- 
menting a query processor for the client and of integrating the 
caching mechanism tightly with the query processor, which 
reduces the portability of the OMRDB. Moreover, their ap- 
proach is probably not helpful in the case of prefetching sim- 



ple objects and relationships. Such prefetches are performed 
by simple queries, which can be statically analyzed during 
OMRDB implementation for the best distribution of function 
between client and server. 

Prefetching also arises in database-driven Web sites, where 
the contents of a page is the formatted output of the execution 
of a query. A general discussion of Web-oriented prefetching 
techniques is in [25]. A particular technique that is similar to 
ours appears in Florescu et al. [13]. They consider a variety of 
optimizations for computing queries that generate Web pages, 
some of which involve prefetch. In their model, a Web site's 
content consists of a set of pages (i.e., query results), which are 
represented by nodes of a graph. Navigating from one page 
to another involves executing a query, which is the label of 
the edge connecting the two nodes. Frequently, the query q 
that navigates from one node to another is related to queries 
executed for earlier pages that the user requested. For example, 
the result of a previous query q ! may either be a sub-query of q 
or have significant overlap with q. hi this case, when evaluating 
q\ it can be beneficial to retrieve and cache extra data that can 
speed up the later evaluation of q. This retrieval of extra data 
amounts to a prefetch. Florescu et al. show how to derive a 
query q" from q and q f and how to use the cached result of q f/ to 
evaluate q and q f , which they call lookahead computation. One 
variation, called optimistic lookahead, is strikingly similar to 
MA and MR; when executing q\ they also prefetch the data 
needed for the next query q for all possible bindings of g's 
parameter. An example of this in our scenario is prefetching all 
relationship collections reachable from the objects in a given 
collection context. Another example is caching the result of 
ExecuteQuery {q f ) to reuse it when issuing a query q for the 
state of objects returned by q l . 

Comparing the scenario of [13] to the problem of this pa- 
per, it is as if the application that uses our OMRDB were 
represented as a data-flow graph, where the edges are queries 
issued by the OMRDB in response to application requests, 
such as ExecuteQuery, GetObject, and GetNext. Then, one 
could use the lookahead techniques of [13] to reuse the (par- 
tial) results of earlier queries when evaluating later ones. The 
question is: Will successive queries issued by tools against 
an OMRDB generate overlapping queries that could benefit 
from lookahead computations? In the Web scenario for which 
these lookahead computations were developed, such overlap 
is quite common, since users progressively narrow their search 
as they navigate through a sequence of pages. Whether such 
overlaps occur frequently for arbitrary applications that use an 
OMRDB is more problematic and could only be determined 
through analysis of typical workloads. Such overlaps would 
need to be very common to justify the substantial engineering 
cost of applying the lookahead technique to OMRDB appli- 
cations, which would require analysis of the application to 
extract the data flow graph, in addition to the optimization 
work described in [13]. 

As mentioned in the Sect. 1, clustering objects on pages 
in a POODB amounts to a static prefetching algorithm. A 
more dynamic version of this approach is the hybrid adaptive 
caching algorithm (HAC) used in the THOR system [20]. In 
HAC, each fetch is for an entire page. However, when a page 
is selected for replacement, popular objects in that page are 
copied to an object cache before the page is evicted from the 
page cache. Thus, each page-oriented fetch can be viewed as 
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a prefetch of a collection of objects, where prefetching errors 
are corrected when the page is evicted. 

8 Conclusion 

We described a technique for predicting useful prefetches 
when a navigational object-oriented interface is implemented 
on a relational DBMS. We presented a design for the technique 
and measured its performance in a commercial product, Mi- 
crosoft Repository 2.0. We proposed a number of extensions, 
some of which would benefit from further work, such as au- 
tomatically issuing hints to enable the prefetch optimization 
and prefetching across paths of relationships. 

Overall, there has been much published about efficient im- 
plementations of persistent objects. Having worked on an im- 
plementation of persistent objects on a relational database for 
the past several years, we feel that the problem of optimizing 
the performance of such a system is only partially understood 
and would benefit from much more research. Given the advent 
of object-relational DBMSs, and the need to offer persistent 
object interfaces on top, the importance of this problem is 
growing. 

Appendix - Summary of 007 

The 007 benchmark is based on a bill-of-materials database. 
In the medium-sized database, there are 500 composite parts, 
each of which has an associated document and 200 intercon- 
nected atomic parts (i.e., 100 000 atomic parts in all). There 
is also a seven-level assembly hierarchy, starting from a sin- 
gle root. Each non-leaf assembly has three subassemblies, so 
there are 729 (~ 3 6 ) leaves, which are called base assem- 
blies. Each base assembly has 3 randomly selected composite 
parts. The following queries and retrievals are taken from [6], 
paraphrased to save space: 

Q 1 - Given 1 0 random atomic part IDs, get the atomic parts 

(that exist) and the number retrieved. 
Q2 - Given a range of dates containing the last 1% of dates 

in atomic parts, retrieve the atomic parts. 
Q3 - Given a range of dates containing the last 1 0% of dates 

in atomic parts, retrieve the atomic parts. 
Q4 - Given 1 00 random document titles, for each document, 

find all base assemblies that use the composite part 

corresponding to the document. Also return the number 

of such base assemblies. 
Q5 - Find all base assemblies that use a composite part 

whose build date is later than that of the base assembly. 

Also report the number of base assemblies found. 
Q7 - Scan all atomic parts. 

Q8 - Find all pairs of documents and atomic parts where the 
atomic part's document ID equals the document's ID. 
Return the number of pairs found. 

T 1 - Traverse the assembly hierarchy. For each base assem- 
bly, visit its composite parts. For each composite part, 
do a depth first search on its atomic parts. When done, 
return the number of atomic parts visited. 

T2 - Same as T 1 , but swap attributes x and y for some of the 
objects: 

a. Update one atomic part per composite part. 



b. Update every atomic part encountered. 

c. Update each atomic part in a composite part four 
times. 

T3 - Same as T2, but update the (indexed) date field. 
T6 - Same at Tl , but for each composite part, visit only its 
root atomic part. 

Note that there is no Q6, T4, or T5 in 007. Traversal s T7 and 
T8 are omitted because they run very fast and therefore lead 
to inaccurate (high variance) measurements. 
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